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1 Executive Summary 


Shrinking government budgets require innovative approaches to reusing existing software 
systems. In particular, the development costs of new safety-critical software can be signifi- 
cantly reduced if existing software components can be reutilized. One common approach to 
enhancing the reusability of code is to write in an object-oriented language, and reuse the 
objects and subclasses in future software systems. But reuse of software components can 
only be done successfully if the software is of high quality in the new system. 

The frequent and incorrect assumption driving the “reuse craze” is that if a software 
component operates successfully in a particular environment (which encompasses both the 
hardware/system environment and the component input distribution), then it will necessarily 
operate successfully in other environments; this is dangerously optimistic! Studies have 
shown that input distribution changes to software components can significantly impact (both 
positively or negatively) the reliability of the component. To assure the quality of reused 
object-oriented components as safety critical subsystems, we require ways to quantify how 
testable those components are with respect to their new environment. Conjectures exist 
that suggest that OO systems, because of their unique attributes, will be of low testability, 
regardless of the operational environment. 

When this effort began, we suspected that although object-oriented designs have fea- 
tures particularly supportive of software reuse, this paradigm is detrimental to system level 
testing for fault detection. After comparing the testability of both OO and procedural sys- 
tems, this Phase I effort researched ways to design critical OO systems for reusability, while 
maintaining an acceptable level of testability. By studying whether this family of program- 
ming languages and design paradigm are harmful to testability, and evaluating methods to 
increase testability, we have provided NIST with critical information that must be carefully 
considered before OO languages are endorsed as tools for developing safety-critical software. 

This Phase I effort studied the impact of inheritance, polymorphism, function over- 
loading, encapsulation, information hiding, alternative testing distributions from the ultra- 
dependable input subdomain, and software assertions on object-oriented systems. Recom- 
mendations for how to maintain sufficiently high testability while maintaining object-oriented 


design (OOD) were developed. Our major recommendations are: 


1. Formal methods, although capable of demonstrating dependability of objects, do not 


demonstrate that the manner in which the objects are linked together produces a 


dependable composition. 


2. Assertions appear to have the greatest ability to preserve OOD while increasing testa- 
bility and hence decreasing testing costs; also, we have provided a simple lemma of 


why software assertions cannot lower software testability. 


3. Information hiding and encapsulation are detrimental to state error propagation, which 


is very necessary if faults are to be found via software testing. 
4. Abstract data types have little impact on software testability as far as we can determine. 


5. Inheritance is not necessarily detrimental to software testability; however, when it is 
combined with information hiding, it may become a “lethal” combination. Unit testing 
costs increase as the depth of inheritance increases due to the number of drivers and 
stubs that are necessary. As a counter argument, subclasses tend to be simpler in deep, 
complex inheritance trees and hence increase the ability to asses high reliability of the 
subclasses. This presents another related problem: the reliable composition of reusable 


subclasses. 


6. Polymorphism is difficult to test, i.e., find test cases to exercise different binding sce- 
narios. However from our previous intuition and this effort’s experimentation, poly- 
morphism, when faulty, causes the faults to be of larger sizes, and that means increased 


testability, and hence it is not problematic for testing. 


7. Testing via an inverted operational distribution allows the study of the fault-tolerance 


of the ultra-dependable region of the input space. 


RST Corporation’s Phase II innovation will be an object-oriented (OO) testability im- 
provement tool that will assist in injecting assertions into OO systems (at those regions of the 
code where testability is demonstratively known to be poor) so that reused objects are tested 
sufficiently, allowing the composite system to be considered as being of high testability. A 
software testability improvement tool capable of improving testability during validation for 
safety critical object-oriented software has tremendous commercial potential in the defense, 


avionics, medical, nuclear, transportation, and manufacturing domains. 


2 Additional Information on the Innovation 


One area needing attention the development processes of critical software applications is 
showing that non-exhaustive testing provides a high confidence in the correctness of the 
software. Unfortunately, the most common validation technique, software testing, is gener- 
ally unable to assess mission-critical levels of reliability, i.e., a probability of failure less than 
10-°. However, software testability analysis can sometimes be used as a complementary 
validation technique for determining whether assessing higher levels of reliability via testing 
is feasible for a specific system. A system with high testability receives greater benefit from 
testing than if it had low testability, thus allowing one to assess higher confidence. 

Assessing a probability of failure less than 10~° is generally infeasible, regardless of lan- 
guage, e.g., procedural, functional, or object-oriented. It is desired that critical systems have 
the highest possibility of revealing faults during system level testing. In contrast, it is de- 
sirable for the same system to hide any remaining faults during operation once the software 
is released. As conjecture, if we have plans to test a system 1,000 times, we would prefer 
to have a source language that only provides syntactic mechanisms that are likely to reveal 
faults when tested with 1,000 inputs. 

Previous research has conjectured that procedural languages are less likely to hide faults 
during system level testing than are OO languages. On the other hand, object oriented 
languages show advantages for developing software that is highly maintainable, readable, 


structured, and reusable. Thus for safety critical software we have a conflict: 


We would like to use OO languages to ease the process of reusing components but 
might then pay a price in terms of reliability (which for safety-critical systems we 


cannot afford). 


Besides studying the relationship between Object-Oriented Design (OOD) and testability 
via C++ examples, this Phase I effort has recommended testing innovations that assess the 
fault masking of object-oriented software. We have developed recommendations for increas- 
ing the testability of OO systems through specific validation and design techniques. Before 
object-oriented languages are applied wide-spread to critical applications, it is vital that: 
(1) the software engineering community better understand what the ramifications of their 


unique features are, and (2) we know how to reduce the likelihood of catastrophic software 


failures hiding from testing. By performing this effort, RST Corporation has advanced the 
state of the thinking about the impact of OOD on software testing. 


2.1 Importance of the Problem 


Computer software verification is generally approached in one of two ways: (1) software 
testing, or (2) proof-of-correctness. Software testing is typically an empirical technique 
that dynamically executes the software and checks the correctness of the outputs. Software 
testing requires a way of generating the inputs and a means of determining correctness. 
Software correctness is theoretically determined by a specification. In practice, the means 
for determining an (input, output) pair’s correctness is either a human or an oracle — a 
correct implementation of the specification. Unlike software testing, proof-of-correctness is 
not empirical nor dynamic, and mathematical proofs are constructed to show functional 
equivalence between a specification description and the function computed by the code. To 
perform a proof-of-correctness, a formal specification is required. 

For critical software systems, i.e., software systems that threaten life if failure occurs, the 
inability to guarantee failure-free operation without either exhaustive testing or performing 
a formal proof-of-correctness is troubling. Dijkstra [8] showed that exhaustive testing was 
generally infeasible by illustrating that exhaustively testing a program that accepts 2 32- 
bit integers would be completed in approximately 585,000 years (assuming non-stop testing 
was performed at a rate of 1,000,000 successful test executions per second). Formal proofs- 
of-correctness are generally not possible for software systems because (1) there is no way 
to prove that the proof is correct, (2) the specification may be ambiguous, and (3) the 
specification may not be what was desired. Because of these problems, proofs-of-correctness 
are infrequently attempted. Since exhaustive testing is infeasible (due to the enormous 
size of the input domain) and proofs-of-correctness are rarely attempted, we are forced to 
accept some degree of risk of today’s critical software systems failing with life-threatening 
consequences, regardless of which overall verification approach is attempted. Now consider 
the additional burden and risk that is added if we are developing software in a language even 
more likely to hide faults. 

Software testing is frequently practiced as a “black art”. Further, since software testing 
occurs late in the software life-cycle, those resources allocated for testing are frequently con- 


sumed at earlier software development phases, usually due to unanticipated design problems, 


or inaccurate development cost estimates. Thus testing efficiency is an important issue, be- 
cause we need as much “fault revealing ability” as possible from available testing resources. 
(Fault revealing ability refers to the likelihood that a particular test case or testing strategy 
, will notify us of existing faults.) 

Software that has not failed during non-exhaustive software testing is both boon and 
curse. We term software testing that has not yet resulted in failure as successful testing. 
Such software is boon for the manufacturer since no defects are known to exist, yet the user 
inherits the risk of discovering defects that are yet unknown. Successful testing makes it 
difficult to assess whether the inputs that are being selected have an acceptable ability to 
reveal existing faults. Thus successful testing is problematic from the standpoint of being 
able to put a number on the reliability or mean time to failure of the system. 

The problem with software that has not failed during testing is merely the adage first 
brought to attention by Dijkstra [8]: non-exhaustive software testing can reveal the existence 
of errors but cannot determine the absolute absence of errors. A piece of software that has 
not failed during testing (when testing has used a “fixed” and non-exhaustive set of inputs) 
does not guarantee that a failure cannot occur for inputs not in the set. Although successful 
testing provides a confidence that the software will never fail, it only provides a confidence 
— it does not guarantee it [22]. 

Today, virtually all critical and non-critical software undergoes software testing. Since 
testing is a considerable expense in developing software systems, with estimates ranging 
between 20% and 50% of all software development costs [5], it is vital that the software testing 
that is performed provide the greatest confidence possible in the reliability of the software. 
Software testability analysis is a measure that is capable of increasing this confidence. 

Different syntactic constructs in a program make it easier for a program to hide faults 
during testing. Not only are the constructs an issue, but how all of those individual constructs 
are hooked together is also very important to whether a program is likely to expose faults 
during testing. Since different programming languages provide different constructs, it is only 
natural to expect that different languages and classes of languages will vary in how efficient 
these languages are in terms of their testing costs. 

In the object-oriented paradigm, objects are atomic units of encapsulation, classes manage 
collections of objects, and inheritance structures collections of classes. Objects partition the 


state of computation into encapsulated units. Each object has an interface of operations that 


control access to an encapsulated state. The operations determine the object’s behavior, 
while the state serves as a memory of past executions that might influence future actions. 
Note that procedural and object-oriented languages differ sharply in their patterns of resource 
sharing. Procedure-oriented languages encourage autonomy at the procedure level, while not 
encouraging interaction through nonlocal variables. Object-oriented languages discourage 
procedure autonomy, and instead organize procedures into collections of operations that 
share an object’s state through nonlocal variables. Thus encapsulation at the level of objects 
derives its power by abandoning encapsulation at the level of procedures. It is our conjecture 
that encapsulation at the object level is very detrimental to overall system testability. 

When we talk about a potential problem with the OOD philosophy and software testa- 
bility, we are talking about testability assessments at the system testing level, not the unit 
testing level. Small objects and classes can be tested quite thoroughly in isolation, but it 
is at the higher levels of object composition where we suspect that there is a reduction in 
testability, e.g., due to capabilities afforded the developer such as private and protected 
data objects. There are cost benefit and reuse claims for why OO languages should be used, 
and we are not in disagreement with these claims. For example, given the enormous costs of 
software, maintenance and reuse are characteristics that OO languages support nicely. So 
from an economic perspective, those are advantages. But from a testing perspective, OO 
languages may hide catastrophic faults for longer time intervals, and if true, this makes test- 
ing such systems more difficult, and hence the benefit of these languages must be brought 
into question. 

In summary, we have studied the feasibility of building an object-oriented software testa- 
bility improvement tool that can be used in conjunction with RST Corporation’s C++ 
Software Testability Analysis Tool (7™) or as a standalone assertion injection tool. We have 
also produced a set of recommended validation and design techniques that will improve testa- 
bility, and as a side benefit, the testing of OO systems. If awarded a Phase II effort, RST 
will provide NIST with a means of improving the testability of C++ systems; to do so within 
the Phase II cost limit, RST will leverage knowledge gained from building next-generation 
software assessment tools. Here, RST will rely on experience gained during the building 
of RST’s C and Fortran-77 testability tools, as well as the experimental results from this 
Phase I effort (which required our building a prototype C++ front-end for PxSCES Soft- 


ware Analysis Toolkit’™™)). Such a Phase II innovation can also be used by NIST or other 


US Government agencies to empirically research the fault masking ability provided between 


procedural and object-oriented languages. 


3. Phase I Technical Objectives 


The research in Phase I contained three objectives. 


1. The first objective was to empirically verify differences between object-oriented and 


procedural languages in terms of their testabilities. 


2. The second objective was to research how the testability of object-oriented software 


can be increased. 


3. The third objective was to determine the feasibility of developing a prototype testability 


assessment system for use on object-oriented systems. 


3.1 Detailed Explanation of Objectives 


Our work in this effort focused on the feasibility of developing a system that improves the 
_ testing of critical software components in object-oriented languages such as C++ and Ada. 
Such an innovation would allow OO software developers to gain confidence that their reusable 
components are not hiding faults after testing has been completed. The following subsections 


describe the three Phase I objectives in greater depth. 


3.1.1 Verifying the Differences in Testability by Language Type 


Our first objective was to empirically determine whether choice of source language has an 
effect on software testability. By quantifying the difference in testability between the same 
function computed by both an object-oriented and procedural implementation, RST was able 
to explore the testability impact of OO software development. We focused our efforts on 
quantifying the detrimental effects that encapsulation and information hiding have on error 
propagation. The results of this objective drive the recommendations as to how testability 


can be increased for OO systems in Objective 2. 
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3.1.2 Increasing Testability for OO Systems 


Given successful completion of Objective 1, Objective 2 concentrated on ways in which 
testability can be increased, either at the design phase, or at the verification phase. Clearly 
we would prefer to find methods at the design phase that will increase our testability before 
the code is produced, but to assess testability, we must have the code; this is a “catch-22.” 
Regardless, this objective sought to discover both software design methods and test methods 
that can improve testability assessments. The following paragraphs discuss our approach to 


this objective in more detail. 


Examining Design Methods A critical task in determining the feasibility of increasing 
testability was to estimate how easily and efficiently OO design/code information can 
be modified to attain higher testability. This portion of Objective 2 studied specific de- 
sign and coding “tricks” that appeared to potentially increase testability assessments, 
keeping important software characteristics as efficiency, structure, and performance 
in mind (after all, if we were to recommend design criteria that parallel those of the 
procedural paradigm or perform at an inadequate speed, then we have effectively de- 
stroyed the advantages of using object-oriented languages). For this part of Objective 
2, RST has produced a set of recommendations to NIST as to how OO systems can 


have improved testability given a specific test scheme. 


Examining Test Methods We had previously observed that different testing techniques 
could greatly impact the testability of a system, but to what degree (as a general “rule 
of thumb”) was unclear. This part of Objective 2 researched ways of minimizing the 
impact of lower testability through better (or at least specialized) testing methods. 
Also, previous work to this effort had suggested that assertions and internal informa- 
tion validation would be good for increasing software testability (as well as being a 
big advantage during testing). So we investigated the prospects for injecting formal 
assertions before assessing testability and using those assertions during OO system 


testing. 


Verifying that Different Methods Improve Testability The final part of Objective 2 
was to empirically assess the impact that our design and testing strategies have on 
object-oriented design. RST used its current software testability assessment tool, 


PiSCES, with its prototype C++ front-end filter, to analyze these impacts. 


Fh 


3.1.3 Feasibility of Implementing a Prototype System 


The final Phase I objective was to take the recommendations from Objectives 1 and 2 and 
determine whether implementing an OO testability assessment tool is feasible. First, it is 
necessary to determine for what language such a tool would be built. Without question, the 
language most widely used for OO systems is C++, and hence our recommendations here 
are with respect to that language. Smalltalk is used in many applications areas, but to our 
knowledge is not in near as widespread use as is C++. 

Since such an innovation is feasible, and RST Corporation has already developed a rudi- 
mentary prototype C++ testability assessment capability onto its Testability Analysis Tool 
from the PiSCES Software Analysis Toolkit'™™)!, this background work allows us to propose 
a testability enhancement tool for Phase II. This tool will allow assertion information to be 
utilized to increase testability in places where testability has been determined to be low. The 
result of Objective 3 heavily drives the determination as to whether a prototype testability 
improvement capability for C++ should be built under a Phase II effort. 


3.2 Questions To Prove Feasibility of Approach 


Our Phase I initiative was geared towards determining the feasibility and practicality of 
producing OO systems with higher testability than is currently being done. The conjecture 
surrounding this effort was that OOD was detrimental to software testing’s ability to detect 
system level faults. 

Software reuse is a nationally important goal, however it is prudent to determine the ram- 
ifications on validating these systems before we, as a national, move further into widespread 
endorsement of the OOD principles. The questions that we have answered fully or at least 


partially addressed in this study are: 
1. How testable is your typical OO code that is produced today? 


1There were several reasons why RST Corporation went ahead and started building this system: (1) we 
needed it for the Phase I effort since our C++ to C translation was determined to be an invalid approach. 
(2) we were able to leverage off of a C++ software safety assessment tool that is being built for the new 
software control system of the BART subway (San Francisco). Since our testability assessment methodology 
is a superset of the safety assessment methodology, it was natural to build and use the necessary C++ 
front-end in PiSCES. (3) also, there are several other “high-visibility” joint commercial ventures that we 
currently are under non-disclosure agreements on, all of which use the same C++ front-end for other tools 


within PiSCES. 
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2. What design-for-testability heuristics should be taught to those that write in OO lan- 


guages? 


3. What different validation testing schemes or internal validation schemes can also be 


employed to improve testability? 


4. What will be the impact on the efficiency of the code if the method for implementing 


the code is modified to increase testability? 
5. How applicable are our recommendations to implementation? 


Through our exploring of these questions and their answers has the feasibility and useful- 
ness of developing a testability assessment and improvement framework for object-oriented 


languages been determined. 


4 Phase I Work Plan 


Section 4 reviews the Phase I work plan that we proposed and followed. We will begin by 
giving two different perspectives on testability assessment, static vs. dynamic. In this effort, 
we concentrated on the dynamic approach, however for completeness, we will describe our 


static approach, because it works equally well with the recommendations from Task 2. 


4.1 Our Basic Static and Dynamic Testability Approaches 


For clarity, we must define what we mean by the term “software testability”; our defini- 
tion differs slightly from the way others commonly use the term. Until recently, the term 
“software testability” had been considered to be a measure of the ability to select inputs 
that satisfy certain structural testing criteria, e.g., the ability to satisfy various code-based 
testing coverages. For example, if the goal is to select a set of inputs that execute every 
statement in the code at least once, and it is virtually impossible to find a set to do so, then 
the testability ascribed would be lower than if it were easy to create this set. 

In an effort to minimize the risk of performing too little testing and becoming excessively 
confident in the absence of faults, Voas [21, 14, 15] redefined the term software testability. 
Voas defines “software testability” to be a prediction of the probability of software failure 


occurring due to the eristence of a fault, given that the software testing is performed with 
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respect to a particular input distribution. Other well-known researchers have since accepted 
this new definition in their research initiatives [10]. This definition says that the testability 
of the software is strictly related to the ability of the software to hide faults during testing 
when the inputs are selected according to some input selection scheme D. This definition 
indirectly addresses the amount of textual coverage achieved during testing. If large regions 
of a program are infrequently executed according to D, both of these definitions of software 
testability would converge, producing a lower software testability prediction. However Voas’s 
definition of testability does not go the next step and assert that the ability to easily execute 
all code regions implies that faults are not hiding; it considers other factors before such a 
strong assertion can be justified. 

In Voas’s definition, if we observe no failures while testing (given input selection tech- 
nique D), we can assert high confidence that faults are not hiding only if we have a priori 
knowledge that the testability of the software was high. However, if after testing according 
to input selection technique D, we observe no failures and are told that the testability of 
the software is low, we gain less confidence that faults are not hiding. This view of software 
testability provides a way of quantifying the risk associated with critical software systems 
that have demonstrated successful testing. The other factors considered before this defini- 
tion of testability converges with the coverage-based definition of testability is provided by 


a technique termed “sensitivity analysis” {21, 14, 15]. 


4.2 The Sensitivity Analysis Model 


The sensitivity analysis (SA) process [21, 14, 15] allows a tester to determine when testing 
can stop with an acceptable confidence that no faults are hiding. Sensitivity analysis also 
predicts where existing faults could be hiding. This allows testing resources to be directed to 
those regions of the code that have shown the greatest potential of hiding faults. Essentially, 
sensitivity analysis gives a road map into the code; it identifies regions that have the greatest 
potential to hide faults. 

Sensitivity analysis complements software testing. It does not identify faults; correctness 
is never an issue. Instead, sensitivity analysis identifies “locations” in a program where 
faults, if they were to exist, are more likely to remain undetected from tests. In sensitivity 
analysis, a location is defined to be either an input statement, output statement, assignment 


statement, or the <expression> part of a while or if statement. 
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Sensitivity analysis requires no oracle nor specification, however it does require that 
inputs are selected at random consistent with an assumed input distribution. Preferably this 
input distribution will be the operational distribution, however there are certain instances 
where a uniform distribution may be substituted. 

Sensitivity analysis makes predictions concerning future program behavior by using es- 
timates of the effect that (1) an input distribution, (2) syntactic mutants, and (3) changed 
data values in data states have on current program behavior. After observations of the be- 
havior of the program under these scenarios are taken, sensitivity analysis predicts properties 
concerning future program output behavior if faults exist. These three scenarios simulate 
the three necessary and sufficient conditions for software failure to occur: (1) a fault must be 
executed, (2) a data state error must be created, and (3) the data state error must propagate 
to the output. Sensitivity analysis has a sound formal basis; it directly approximates the 
conditions necessary for software failure. 

RST Corporation has developed an automated sensitivity analysis tool called PiSCES 
Software Analysis Toolkit'™™). PiSCES enables RST to assess the testability of procedu- 
ral software. Using this tool, RST has developed some preliminary design-for-testability 
metrics that are the starting point for our object-oriented design recommendations. Dur- 
ing Phase I, RST used PiSCES to measure software testability, develop testing schemes to 
increase testability, and develop additional design heuristics. The following subsections de- 
scribe the preliminary design-for-testability work that RST has performed, and drive the 


development of new design approaches specifically for object-oriented systems. 


4.2.1. The Domain Range Ratio Static Testability Metric 


Developing software design recommendations that enhance testability is difficult, because at 
the design level we no longer have access to an input distribution for the software. Realize 
that testability is a metric that can be quantified at the specification, design, and code level, 
however it is usually less precise at the design and specification levels. This is because testa- 
bility information is based upon an operational profile of the expected inputs and is easiest 
to estimate through dynamic execution of developed software. To predict testability before 
code generation, heuristics must be found that correlate with actual testability estimates 
collected during dynamic analysis of developed code. Identifying these correlation’s between 


dynamic testability information and static design structure is the challenge that must be 
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overcome to develop design heuristics. 

During the design/implementation of software, we can isolate certain sub functions of 
the software that will tend to hide faults. RST researchers have developed an initial metric 
to estimate this design characteristic called the Domain Range Ratio. The Domain Range 
Ratio, or simply DRR, is the ratio of the cardinality of possible inputs to the cardinality 
of the possible outputs for any function. We have used this metric to better understand 
how information hiding and encapsulation (that are central to OO languages) affect OO 
languages. By isolating components that implement a high DRR function during design, we 
are able to produce programs that have higher testability and hence are easier to maintain. 
For certain designs, this technique produces programs that require less additional testing 
when the assumptions about the input domain change. We believe that the established DRR 
metric is only the tip of the iceberg concerning approaches to applying testability information 
to generating higher testability automated code. Our research in this proposal will build 
upon our basic understanding of the issues in this area to design object-oriented systems 
that exhibit higher testability. The following discussion details our findings associated with 
DRR and enumerates how we believe these findings affects the overall objective of this effort. 

We denote the DRR of a design by A:B, where A is the cardinality of the domain, and B 
_is the cardinality of the range. Generally as a DRR increases, the testability of the resulting 
software decreases. When A is greater than B, previous research has suggested that faults 
are more likely to hide during testing than when A=B [20]. 

The DRR (as we have defined it) depends solely on the number of values in the domain 
and range, not on the relative probabilities that individual elements may appear in these sets. 
This simplifies the calculation of the DRR, and makes it more likely to have a reasonable 
approximation of the DRR at design time. Although the input distribution to the software 
can change the DRR, the DRR is not as sensitive to distribution changes as, for example, 


such semantic metrics as probability of failure or reliability. 


4.2.2 Internal State Collapse 


This section explains one characteristic in the software that we know lowers software testa- 
bility, and that DRR can predict. For certain functions, the inputs can be found from the 
outputs by inverting the specification. For example, for an infinite domain, the function f(x) 


= 2x has only one possible input x for any output f(x). Other functions, for example f(x) 
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= tan(x), can have many different x values that result in an identical f(x); i.e., tan-1(x) is 
not a one-to-one function. All inverted functions that do not produce exactly one element of 
the domain for each element of the range lose information that uniquely identifies the input 
given an output. Restated, many-to-one functions mandate a loss of information; one-to-one 
functions do not. 

An implementation of a many-to-one function has information in its internal states that 
is not communicated in its output. This corresponds to a DRR of A:B, where A > B. We 
term this phenomenon internal state collapse. An internal state is a collection of all live 
variables along with their current values at some point during execution. A live variable is 
any variable that has the potential for affecting the software’s output. Also, the program 
counter is considered live. Thus observing internal state collapse is also part of our approach 
to developing new design criteria. 

When internal state collapse occurs, we run a risk that the lost information may have 
included evidence that internal states were incorrect. Since such evidence is not visible in the 
output, the probability of observing a failure during testing is reduced. As the probability 
of observing a failure decreases, the probability of hidden faults increases. 

Any implementation of a module with A > B must lose information, and this loss suggests 
a lower module testability. We therefore can examine a DRR for a module and know before 
implementation how much internal state collapse will occur. This a priori information can 
be thought of as a rough approximation of the software’s testability and can estimate the 
amount of testing necessary to overcome this situation. 

Each assignment of a value to a variable is a subfunction of the overall function being 
computed (meaning the module or program). Variables that are restricted to a small set of 
potential values will frequently suffer from the effects of internal state collapse, and these 
variables warrant special consideration during validation. Internal state collapse is a discrete 
parallel to a rule of thumb in analog measurement: ”the less accuracy in the output, the 
greater the chances of a mistake going unnoticed.” 

Integrated circuit design engineers have a notion similar to internal state collapse that 
they term “observability.” Observability is the ability to view the value of a particular node 
that is embedded in a circuit [12]. When internal state collapse occurs in software, we have 
lost the ability to see information within the internal state of the program. So in this sense, 


internal state collapse in software is a parallel to lower observability in hardware. 
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Discussing the observability of integrated circuits, [2] states that the principal obstacle 
in testing large-scale integrated circuits is the inaccessibility of the internal signals. One 
method used for increasing observability in integrated circuits design is to increase the pin 
count of a chip, allowing the extra pins to carry out additional internal signals that can be 
checked during testing. These output pins increase observability by increasing the range of 
potential bit strings from the chip. 

We advocate a software design strategy that parallels the hardware strategy of increased 
pin count for testing: during the design of safety critical modules, the number of output pa- 
rameters can be increased to reveal more internal information in the output. This additional 
internal information increases the probability of discovering faults that would otherwise be 
difficult to reveal during testing. This additional information is indicated by a reduced Di. 
Hoffman [9] has suggested a similar finding between software modules and integrated circuits. 

Internal state collapse occurs in at least two ways. First, the number of live variables 
in an executing program can decrease as execution continues, until finally the only live 
variables are the output variables. When an erroneous live variable becomes dead, unless 
the variable transfers its “incorrectness” into another live variable before becoming dead, 
this incorrectness will be invisible during testing. 

A second way that internal state collapse can occur is when two different program states 
are presented to a particular sub function in a program and that sub function produces the 
same internal state in both cases. For example, assume that f(x) = x?. Both x = 5 and x 
= -5 produce the same internal state after executing x := f(x). It may be that the negative 
integer could signal a problem with the software, but f(x) will erase that information in 


subsequent output. 


4.3. Concluding Remarks on Software Testability and the DRR 
Metric 


The information produced by Voas’s testability model is used by sensitivity analysis to make a 
prediction concerning the ability of a program location to hide faults during testing according 
to D. This prediction provides the ability to determine whether the increase in confidence in 
a location’s correctness produced from successful testing according to D is justified. When 


taken over all locations in a program, this can be translated into a prediction of how much 
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testing is minimally needed for critical programs. . 

Voas has conjectured that there may be a theoretical upper bound on the testability 
achievable given a particular mathematical function that we wish to compute. It is unknown 
whether such exists, nor whether the upper bound is computable. However what it does 
suggest is that various program designs, implementations, and languages all contribute to 
the resulting testability given a fixed input distribution. Thus as a side- effect of this research, 
we hope to better determine whether the existence of such a theoretical upper bound is a 
realistic conjecture. 

With PiSCES, RST is able to assess the testability of a particular region of a program in 
an automated fashion. This gives RST the unique ability to quickly explore the impact that 
design and testing strategies have on the testability of object-oriented systems. Also, RST 
has previously done research into design-for-testability and was prepared to extend this work 
to object-oriented systems. We have shown that concepts such as a high DRR, information 
hiding, information loss, variable reuse, and internal state collapse are detrimental to testa- 
bility. In summary, we feel that our technology and this Phase I report provides NIST with 


accurate information for studying this problem that is of national importance. 


5 Phase I Results 


As stated in the technical objectives section, we built upon our knowledge of testability 
to determine how testable object-oriented systems currently are, and how their testability 
might be improved. The work in Phase I of this program examined the issues associated with 
assessing OOD testability, finding design methods or testing schemes that lend themselves to 
higher OO system testability, and make recommendations as to the feasibility and practicality 


of building a prototype testability improvement tool. 


5.1 Task 1: Analyzing the Testability of Object-oriented Code 


In the first task, RST examined and compared the testability of C (procedural) and C++ 
(object-oriented) code. RST developed an automatic-teller machine (ATM) program in 
C and C++. PiSCES was then used to analyze and compare the testability of these 
implementations. RST also developed a simple SHAPES drawing package in a similar OO 


vs. procedural technique to use as a test. 
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Our original intuition was that since PuSCES currently operates on C and Fortran-77, 
the C++ software would be preprocessed into C before running it through the tool. To our 
frustration, the translation process did not preserve the semantics of the OOD paradigm 
(such as information hiding), making the results of testability analysis based on translated 
“C++ to C” code useless. This required that RST develop a prototype C++ parser onto 
PiSCES, and then run the analysis with that filter. Care was taken during development of 
the applications such that the OO and procedural versions were written in a manner that 


encompasses the design viewpoints of these paradigms. 


5.1.1 The ATM Experiment 


We now summarize the results obtained by performing propagation analysis on both object- 
oriented and procedural versions of an Automated Teller Machine (ATM) simulation de- 
veloped by RST. The ATM system was coded in both C and C++ from a simple ASCII 
specification. In this experiment, we were focused solely on the impact of encapsulation and 
information hiding. 102 test cases were developed such that all locations in the program 
were covered. The code for these projects is found in Appendix A. 

The Automated Teller Machine (ATM) program simulates a single ATM connected to 
a bank. The machine accepts ATM cards and verifies the validity of the user by accepting 
a PIN number and matching it with the users PIN number maintained at the bank. If the 
user enters three unsuccessful PIN numbers, the machine eats the card and informs the user 
to contact the bank. If valid, the user has access to one checking and one savings account. 
Possible transactions includes: withdrawls, transfers, and balance checks. A transaction 
is invalid if either the user tries to withdraw greater than $200 per access or attempts a 
transfer/withdraw that overdraws an account. Each valid transaction generates a separate 
receipt. All receipts are printed when the user has completed all desired transactions. 

Procedural and Object-oriented versions of ATM were developed from a generic specifi- 
cation including information contained in the previous paragraph. ‘The procedural version 
maintains a set of data structures and a set of procedures that operate on data to perform 
_ the aforementioned tasks. the object-oriented version consists of a set of classes that combine 
to create functioning ATM and bank objects. 

Inputs to the program take the form: 


<atm card> 
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Minimum Inequality [ Minimum Point Estimate | 
Object-Oriented 0.0098 0.011 | 
0.01 0.075 | 


Table 1: The lowest location upper bound and point estimate propagation scores 
for any location in the respective versions. 


# of Inequalities | Percentage of Inequalitites | 
Object-Oriented 16.2% | 
pe | 


Table 2: The total number of locations for which propagation never occurred and 
the percentage of these with respect to the total number of locations. 


<pin number> 
<transactions>* 


<quit> 


Tables 1- 3 summarize the results. The average and minimum scores in Tables 1- 3 are 
based on propagation estimates at the location level. In Table 1, we are showing both the 
minimum inequality and minimum point estimate.” In this table, it is interesting to note 
that the minimum point estimate is almost 7 times larger for the procedural than for the 
object-oriented. Although this may seem large, it should be noted that these values are of 
the same order-of-magnitude. Table 2 shows the number of locations (although not from 
identical code) that demonstrated no propagation was greater in the OO system than in 
the procedural system. But then again, it was too close to draw any statistical significance. 
Table 3 shows that on average, it will take 20% more test cases to test the OO code than 


the procedural code. Once again, this is not a large difference, but it should be noted. 


An inequality occurs whenever propagation never occurred; instead of providing a 0.0 propagation esti- 
mate, we place an upper bound on the point estimate, making it into an inequality. 


| Paradigm Average Propagation Score 
[ Object-Oriented 
[Procedural | Egg 


Table 3: The average propagation point estimate score (this does not include 
upper bounds). 
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Object-Oriented 0.031 
0.033 | 


Table 4: The lowest location upper bound and point estimate propagation scores 
for any location in the respective versions. 


In summary, this example showed that for the same 102 test cases, the OO design with 
encapsulation and information hiding faired worse in enforcing the propagation condition, 
which is necessary to assess higher levels of testability. This experiment suggests that in- 
formation hiding and encapsulation are detrimental to testability, particularly propagation, 


which has been our suspicion for several years. 


5.1.2 The SHAPES Experiment 


SHAPES is a simple draw package that allows various shapes to be drawn, moved, and 
stacked on top of one another. Currently SHAPES supports three basic shapes: lines, 
rectangles, and a simple face (head, eyes, nose, mouth) made out of the first two shapes. 
The program defines a drawing space in which shapes can be manipulated by changing their 
x, y coordinate positions. 

In this example, our OO design enforced inheritance and polymorphism, and function 
overloading in C++, whereas the ATM example enforced encapsulation and information 
hiding. In the SHAPES experiment, we are interested in looking at whether inheritance, 
polymorphism, or function overloading have an observable negative impact on testability. A 
C procedural version was also developed that did not include these features. 

Input values to SHAPES consist of information for creating shapes and manipulating 


them. A SHAPES input file is in the following format: 


<number of shapes> 
<shape type><shape position>* 


<shape manipulation><parameters>* 


All shape diagrams are output to the screen after creation or a refresh. Tables 4- 6 summarize 
the results for this application. 
What this experiment suggests is that inheritance, polymorphism, and function over- 


loading in C++ do not have a negative impact on testability as opposed to the procedural 
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| Paradigm # of Inequalities | Percentage of Inequalitites 
[ Object-Oriented 
[Procedural 0 [95% ha | 20% apubaoen| 


Table 5: The total number of locations for which propagation never occurred and 
the percentage of these with respect to the total number of locations. 


ROO OHii 
Procedural” Mi 01d ae 


Table 6: The average propagation point estimate score (this does not include 
upper bounds). 


version. In fact, in all categories for which we compared results, the OO version appears to 
outperform the procedural version. 

We expected that inheritance, in isolation from information hiding, would not be prob- 
lematic. It is when information is hidden from lower methods that propagation can be 
thwarted. As for polymorphism and function overloading. we also expected no direct impact 


on testability, however in combination with other features. this could be different. 


5.1.3 Task 1 Summary 


Task 1 has suggested that encapsulation and information hiding are detrimental to effective 
fault detection with system level testing. Although this experiment can only be viewed as one 
data point, it does agree with the original hypothesis that was put forth several years ago [20]. 
Additional research is required, but this is seminal evidence from an actual OO system where 
the hypothesis was substantiated. This task has failed to conclude whether polymorphism or 
inheritance are detrimental to testability, given that the OO version produced better results 
than its procedural counterpart. Once again, this evidence must be viewed as a single data 


point and is not conclusive. 


5.2 Task 2: Examining Different Design Methods 


Task 2 researched one specific design-for-testability (DFT) heuristic to the aforementioned 
C++ code, assertions. The size of this effort did not allow us to concentrate resources to 


look at newly developed OO-design paradigms, nor are we convinced from the results of 
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Task 1 that such is warranted. We instead recommend improving the paradigms that are 
currently available. 

An assertion is a test on the entire state of an executing program or a test on a portion 
of the program state.* Although empirical assertions are validation mechanisms, their use 
in hardware testing has earned them the label of “design-for-test” mechanisms, and thus 
we will also consider them here as an approach to improving the design of OO software.‘ 
(“Observability” is the term used in hardware design representing the degree to which the 
inner logic of a chip can be tested.) 

Typically. software testing checks the correctness of values only after they are output. In 
contrast, assertions check intermediate values, values that are not typically defined as output 
by the requirements. The benefit of checking internal states is that testers know as soon as 
possible whether the program has entered into an erroneous state. 

Assertions can be derived at any time during the software life-cycle, however we will only 
use them once code is available. When developing software using formal methods, assertions 
are employed before code is available. Here, we are looking at applying assertions during 
the software assessment phase, but we wish to derive these assertions during design using 
measures for where they should be placed by quantifying metrics such as the DRR. Typically, 
assertions are used during testing (to improve testability) and removed during deployment 
(for efficiency and speed). The removal of assertions however can be problematic, and it 
is preferable that this is done in an automated fashion to lessen the probability of human 
error. Removing assertions after testing is analogous to compiling without the debug flag 
when run-time errors are no longer being experienced. (Assertions remaining in production 
software can be useful in detecting and diagnosing problems.) Also of extreme importance 
are the mechanisms used to derive the assertions from the requirements or specification; 
incorrect assertions can lead to a false sense of a good design process. 

Assertions that are placed at each statement in a program can automatically monitor 
the internal computations of a program execution. However, the advantages of universal 
assertions come at a cost. A program with such extensive intrusive instrumentation will 


execute more slowly. Also, some assertions may be redundant. And the task of instrumenting 


3The type of assertion that we are interested in is empirical assertions that are invoked when the code is 
executed; we are not talking about formal logic pre and postconditions that are used in a “cleanroom” like 


development process. 
4By “improving the design of OO software,” we mean “forcing a more explicit and better specified design.” 


24 


the code with “correct” assertions at each location is of high risk; there is no guarantee that 
the assertions will be correct. 

Our results from this effort advocate a middle ground between no assertions at all (the 
most common practice) and the theoretical ideal of assertions at every location. Our ex- 
periments showed that even OO systems can have regions of quite high testabilities, and 
hence assertions are not warranted. A plausible compromise is to inject assertions only at 
locations where traditional testing is unlikely to uncover software faults. For instance, we 
can statically detect information hiding within a design, and we can easily place assertions 
on encapsulated variables. By doing so, we explicitly test the validity of computations at 
the system and unit level that are normally tested implicitly. 

We will assume that all assertions are logical and evaluate to TRUE when the internal 
state is satisfactory (meaning it passes the particular test in the assertion), and FALSE 
otherwise. When an assertion evaluates to FALSE, we consider the execution of the program 
to have resulted in failure, even if the specified output is correct. You can think of this as 


“artificially” modifying what is defined as failure: 
failure is said to occur if the output is incorrect or an assertion fails. 


In essence, this not only redefines failure, but it modifies what is defined as output. 


5.2.1 Locations Needing Assertions 


To determine where assertions are warranted, we essentially have two options: perform a 
static testability analysis on either the code, design, or specification, or perform a dynamic 
testability analysis on the code. Note that “analysis” does not necessarily imply “auto- 
mated,” however this is preferable. The DRR metric can be automated for any of these 
functional representations, however for our Phase II prototype, we plan to perform this mea- 
surement at the code level as a first proof-of-concept. Also sensitivity analysis was automated 
for the results of this Phase I effort. For the remainder of section 5.2.1, which explains where 
to inject executable assertions, we will assume that a dynamic propagation analysis has been 
performed; we could just as easily have assumed that we had DRRs at the function level, but 
since our experimentation was on the code using our dynamic tool PiSCES, we will explain 
this technique using dynamic results. 


Let L represent the set of all locations in a program, P. Let 0; be the propagation 


25 


estimate or DRR for location /. 6; is an assessment of the likelihood that if a fault hides in 
l affecting the variable assigned at / given a program testing scheme, D, D will make this 
error observable. 

By viewing a location as only affecting one variable of the data state (i.e., no side- 
effects), we can rank all locations in the program according to the 4)s. This ordering provides 
knowledge as to (1) which locations are likely to hide faults during testing, and (2) where 
empirical assertions can be cost-effectively employed. 

To rank locations, we first establish a cut-off score, €, such that locations with scores 
below the cut-off are judged to be dangerously insensitive to faults. For a variable assigned 
a value at one of these dangerous locations, we will place an assertion at that location. 
The assertion is devised to reflect a required state of the computation of that location; 
this information must be extracted from the specification. Our recommendation: create 
assertions for all locations where 0; < €, and inject these assertions immediately after | (this 
set of locations is denoted by L’). 

Assertions come in many different formats: they can be written in the source language 
of the program under analysis, or if external to the program, they can be written in any 
language or even hardwired. For example, an internal software assertion might look like 
ASSERT(program_input_value, y, y > x), which passes the program input value and 
the variable being tested y into a procedure that returns TRUE if y is greater than x and 
FALSE if it is not. The value-added by inserting assertions into software is directly dependent 


on two factors: 
1. Is the assertion correct? and 
2. How “tight” is the assertion? 


We say an assertion is tight if we are able to determine whether the value being tested is 
correct. An assertion is tight with respect to the value that the variable should have at that 
location in the code. Finding a tight assertion is, in general, nontrivial. The opposite of a 
tight assertion is a loose assertion that allows a variable to have a less well specified value; 
such assertions reveal less about the internal state of the computation. 

Assertions will have varying degrees of “tightness.” For instance, we might not be able 
to determine exactly what value y should have at a location, but we might know that 


y should be in the range [0,10]. This is a “looser” assertion than knowing exactly what 
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value it should have. An even looser assertion would be to say that y should have a value 
in [-maxint, maxint]. Clearly, the looser an assertion is, the less information it provides 
concerning correctness and the less confidence that we gain when the assertion is executed. 
The benefit derived from an assertion is directly related to its tightness and correctness. 


The plan for placing assertions is simple: 
1. perform propagation analysis on the original code. 
2. place assertions where warranted by the propagation estimates. 


3. reperform propagation analysis on the code with the assertions; the increase in esti- 
mates from (1) will be a function of the tightness of the assertions. (This will demon- 


strate the quantifiable benefit that the assertions have provided.) 


4. test the code according to the results of (3) with the assertions in place. 


5.2.2 When Assertions are Not Available 


The ability to extract correct assertions from the specification cannot be automatically as- 
sumed; indeed, we anticipate that there will be situations where assertions are either too 
loose or non-existent. In this event, we must find ways (other than testing and assertions) 
to convince ourselves that the locations in L’ do not contain faults. 


Two options immediately present themselves: 


1. Formal Fagan style code inspections, and 


2. Specialized unit testing on the functions that are comprised of one or more members 


Gib 


Manual code inspections and walkthroughs have been shown repeatedly to detect faults and 
be cost effective; one study found that these techniques caught 30-70% of the total number of 
faults [18]. Essentially, these are static, manual assertions. Given that there have been many 
anecdotal successes reported with these techniques, organizations are turning to inspections 
as a way to reduce software development costs, and inspections are also being applied to 
earlier phases of the software life-cycle. Of course the concern with inspections is that faults 
do escape detection, and hence an inspection that does not discover any faults is not a 


guarantee of correctness. 


on 


Specialized unit testing can be performed in many different ways. Recall that sensitivity 
analysis is usually performed at the system level D. (This does not preclude you from 
performing sensitivity analysis using D’ as a unit testing distribution on P’ as a module 
in isolation away from the remainder of the system.) Possibilities for unit testing schemes 
include data flow and simple coverages. More advanced schemes such as mutation can be 


applied if tools are available for the source language of the program P. 


5.2.3. Incorrect Assertions 


Even if assertions are incorrect, they are likely to benefit assessed testabilities. But our goal 
is not merely to use assertions to increase testability, but rather to use assertions as windows 
into the computational state. Thus, correct assertions are far more valuable than incorrect 
assertions. 

This testability-based assertion injection model for OO systems combines ideas that have 
been prevalent in formal methods and empirical testing for decades. When assertions are 
correct, they can deliver information both about testability and correctness. The correctness 
requirement for assertions is costly, but the need for a correct oracle has always been a 
limitation of testing techniques [11]. It is undesirable to simply insert assertions and claim 


that the overall testability is increased. 


5.2.4 Lemma of the Impact of Assertions on Testability 


Here, we wish to give a simple lemma that the impact of an assertion on error propagation 
must either be: (1) negligible, or (2) positive. Error propagation is a direct factor in assessing 
software testability: greater error propagation implies greater testability. As you will see, 


this lemma is intuitive and obvious, and hence we will not belabor the point. 


Lemma: 

Assume that for some program P, all memory that the program has access to is 
contained in a ten-element array: a[0], a{1], ..., a[9]. Assume further that some 
percentage z of that array , 0 < x < 100, is output from P, and all information 
that is output from P is checked by an oracle, O. For any element in a, there is 
a probability (> 0) that either a fault (design error) or corrupt input will cause 


the element to also become corrupted; we denote these probabilities: Pajo), Paw), 
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..., Pajg}. For example, if some element of a is defined in unreachable code, this 


probability is 0.0. 


If c = 100, then all members of a are currently being checked correctness by 
O, and if x < 100, then not all members of a are being checked. If x = 100, 
adding an assertion to check an element aly] that is already being checked will 
not increase the likelihood of error propagation. But if c # 100, and we assert 
on a member of a that is not being checked by O, then unless this data member 


is dead, the likelihood of error propagation must increase. 


This is true because of the basic probabilistic laws: given two events A and B, 
Pr(A) V Pr(B) > Pr(A) 
Pr(A) V Pr(B) > Pr(B) 


In our notation, suppose that a[0] through a[8] are being tested by O; then adding 


an assertion to a[9] must increase the likelihood of error propagation, because: 
Pajo) V Paty V Paz} V Pays) V Paja) V Pats) V Paje) V Pajz) V Pays} 2 


Payo) V Paty V Pag} V Pays] V Pata} V Pais) V Paje} V Payz) V Pars) V Pays) 


This demonstrates that assertions cannot decrease testability, and may actually 


increase it. 


5.2.5 Task 2 Summary 


Assertions represent a valuable design tool for OO systems. Our conclusion parallels the rec- 
ommendations of Osterweil and Clarke in [4], where they classified assertions as “among the 
most significant ideas by testing and analysis researchers.” Our conclusion is also confirmed 
by [3]. 

We have presented a means for logically deciding where assertions are needed in code 
regions that seem unlikely to reveal faults during testing using dynamic testability assess- 
ments. Current schemes for the placement of assertions are often either ad hoc or brute-force, 
placing assertions in random places or everywhere. We contend that our assertion placement 


scheme is sound and practical. 


Realize that static DRR measurements can also be applied to determine where assertions 
will be most helpful. In fact, DRR measurements are ideal for discovering the degree to 
which information hiding is occurring. 

The benefit derived from this use of assertions will be a function of the tightness on 
the assertions. Extremely loose assertions should not be considered sufficient, and loca- 
tions receiving loose assertions are candidates for additional analysis. This testability-based 
assertion method will increase propagation estimates of predecessor locations (determined 
dynamically during execution), whose computations are referenced by the variable being 
asserted on. Not only do we gain confidence from an assertion that the location receiving 
the assertion is not hiding faults, but we gain confidence that faults are not hiding elsewhere 
in the code. Assertions greatly benefit OO testing. 

Hecht [6] has indicated that rarely encountered faults may be the dominant cause of 
safety and mission critical failures. Rarely encountered faults can hide for long periods of 
time even while a system is undergoing testing and debugging that is aimed at reliability 
improvement. If just one rare fault has the potential to lead to a catastrophic failure, then 
we would have a reliable, unsafe system. Hence the goal of this assertion-placement model 
is to reduce the likelihood of any fault hiding in the system, by attacking the program at its 
“weakest” points with assertions. 

Note that the use of assertions for increasing the confidence in safety-critical applications 
is not unique; what is unique about this method is the use of “testability-based” assertions 
that are placed in only those locations in the code where the degree of error masking is 
predicted to be high. In [7], Guiho & Hennebert stated that the validation of SACEM, a 
partially embedded system which controls the speed of all trains on the RER Line A in Paris 
France, required about 100 man-years of effort; assertions were needed for formal proofs. 
The assertions were a critical part of that validation effort; these assertions could have also 
been placed in the code during testing, but apparently were not. The interesting result here 
is that the developers feel that they have achieved a 10~° probability of failure by equipment 
per hour, i.e., this new SACEM system is as safe as the old system that it replaces that had a 
much lower traffic throughput. Hence assertions are a vital entity to have during validation, 
whether they are used for formal proofs (to verify safety code) or as internal self-tests during 
testing. 


This scheme has costs: (1) the decrease in performance during testing, (2) the costs of 
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performing testability analysis, and (3) the cost of deriving assertions from the specification. 
Also, if the assertions are removed before the code is deployed, there will be a slight, addi- 
tional cost. But for critical systems, if a value-added benefit can be demonstrated relative to 
cost for a scheme, the scheme cannot be automatically dismissed. By studying the impact 
of assertions, RST has recommended where to apply them. Also, we have produced a small 
lemma that an assertion can never decrease the propagation condition, 1.e., an assertion can 
only improve or make no change to the propagation condition, which is very important for 


thwarting the negative impact of information hiding. 


5.3 Task 3: Modified Testing/ Validation Schemes 


This task investigated how one specific testing scheme, upside-down operational distributions, 
impacts testability (and conversely, fault-tolerance). We had originally proposed to research 
the application of assertions in this task, but instead moved that research into Task 2. In 
Task 3, we devised a modified means for assessing the testability of OO systems with the 
ultra-dependable region of the input space. 

Software testability is the probability that corrupted data states are observable for the 
test scheme. Fault-tolerance is the probability that corrupted data states are not observable 
by the test scheme. Any measurement of fault tolerance provides an assessment of testability 
and vice-versa. 

Our meaning of the term software fault tolerance in this task is quite different than the 


traditional hardware definition.® We consider a single program to be fault-tolerant iff: 


1. the program is able to compute the correct result even if the program itself suffers from 


incorrect logic, and 


2. the program, whether correct or incorrect, is able to compute the correct result even 


if the program itself receives corrupted incoming data during execution. 


Programs with high degrees of these characteristics have been termed as self-correcting. 


°In fact, even the term “fault-tolerance” when applied to software usually suggests the application of 
multiple versions, multiple processors, or recovery block schemes, but that is not our intent here; we are 
talking about fault-tolerance in the purest sense, where any anomoly that is manifested during execution 
can be thwarted. 
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The best software engineering design practices have argued for robustness and graceful 
degradation whenever a system gets into an undesirable state [19]. Software fault tolerance 
is a related concept, yet distinct. The distinction between robustness and fault tolerance 
rests on whether the undesirable state is “expected” or “unexpected.” Robustness deals 
primarily with problems that are expected to occur, and hence must be protected against. 
In contrast, fault tolerance primarily deals with problems that are unexpected, yet also must 
be protected against. For example, if we are reading in an integer that will be used in a 
division operation, a robust design will ensure that the division operation is not applied if 
the integer is zero. A fault-tolerant design accounts for unanticipated possibilities, e.g., if 
the integer is corrupted, a fault tolerant design might freeze the state of the program and not 
compute the division operation (which is equivalent to an integer divide-by-1), or it might 
require that the integer be reread. In this task, we are interested in assessing fault-tolerance, 


which can be a side-benefit of robust design practices. 


5.3.1 Inverted Distributions: Definitions 


The input space, I, is the set of all legal and possible (meaning a greater than 0 probability) 
input values represented by the specification’s domain. For each member of the input space, 
there is a likelihood that the member is selected during (testing or use). We term those 
members that are likely to be selected during testing as members of the probable input 
subdomain, and the rest are members of the improbable input subdomain. 

Assume that during testing with inputs from the probable input subdomain, no failures 
are observed and the number of test cases used are relatively few (with respect to the number 
of possible input values).® These tests allow us to assess relatively modest levels of reliability. 
Test cases that are likely to be selected according to D represent the portion of the input 
space for which if we knew the program computed correct results, then we could assess 
even higher levels of reliability. To be able to gather this information, we have three means 


available to us: 
1. Test according to D.” 


®These are the inputs with the greatest likelihood of selection in D. 
’This may or may not be equivalent to stress testing as defined by Beizer [1], which tests a system 
according to abnormally high numbers of processing requests in a short time interval. 
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2. Perform a dynamic propagation analysis that can empirically show that when D is 
sampled from, the selected members are incapable of causing the output state to be 
affected by both internal design flaws and corrupted input values that are coming into 


the system from external sources. 
3. A combination of 1 and 2. 


In this task, we looked at the implications of performing the second alternative, and what 
possible impact quantifying the fault-tolerance of D might have on our confidence in the 
reliability of the code. Realize that during the operational life-time of the software, those 
members likely to be selected according to D will almost certainly be fed into the system as 
inputs at some point. So having behavioral/semantic information about whether the code 
is able to recover from problems when those inputs are processed is meaningful. 

The input distribution for a piece of software is a probability density function that assigns 
to each possible input test case 2 a probability that 2 will be selected on a randomly selected 
execution of the software in a certain environment. There are difficulties, both theoretical 
and practical, in obtaining such a distribution [17], but in this task we will assume that an 
estimated input distribution is available. One may always be estimated, though its accuracy 
may be suspect. All true probability density functions D have the property that the sum 
of D(z) over all legal 2 equals 1. Each D(z) is a probability, and thus is between 0 and 1 
inclusive. If a particular D(z) equals 0, then 2 is not a member of the input space as we 
previously defined it. If a particular D(z) equals 1, then it is the only member of the input 
space. 

In this task we examined how to exploit a new distribution which in an informal sense 
“inverts” the operational distribution. Intuitively, we want the new distribution, call it D, 
to assign a large probability to elements that had a small probability in D, and to assign a 
small probability to elements that had a large probability in D. 

Building an “inverse” distribution algorithmically requires several subjective decisions. 
First, what does it mean when D(z) = 0 in D? If it means that 7 never occurs as an input to 
the software, then we should disregard 7 in the new distribution as well; if D(z) + 0 because 
it occurs only very rarely, or because the developer only expects it to be used rarely, then 
we want the inversion to give 7 a relatively high probability of selection. In this task we will 


arbitrarily select the first decision: D(z) will be assigned 0 for each 7 such that D(z) = 0. 
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Next, we must decide how to obtain a new distribution D that captures the intuition of an 
inverse. A true inverse operation would have the property that enverse(znverse(D)) = D, 
but the peculiar properties of a probability density function make this difficult to attain. 


Instead, we offer the following constructive definition of the “inverse,” D: 
Algorithm: 


1. Let N be the number of different legal inputs. Let M = 1/N, the mean of the 
probability density distribution over N possible inputs. 


2. For each element 2, let g'(z2) = 2* M — D(z). 


3. Find the minimum g’‘(z),m. If m > 0, g’(z) is D. Otherwise, proceed to step 4. 


4. When m < 0, let g’(z) = (g'(z) + abs(m))/(1 + N * (abs(m))). Then g” is D. 
An alternative D could be formed by setting all negatives in g’ to zero, and then renormal- 
izing. However, we rejected this because it loses the intuitive idea of retaining the inverse 


shape of the distribution. 


5.3.2 D and Traditional Testing 


In traditional reliability testing with an input distribution, repeated executions (hopefully) 
mimic the conditions that the software will experience in operation. Reliability information 
can then be predicted under assumptions about the accuracy of the input distribution. 
Testing with D does not give this “predicted” reliability. Instead, testing with D will exercise 
the code with less frequently (but still legal) selected inputs. As such, the tester can expect 
to discover software faults that might linger, undetected, for quite some time when the 
software is tested or used by customers under situations anticipated by the developers. (For 
example, an incorrect exception handler might be caught if an unlikely input that exercises 
the handler is chosen.) However, these undetected errors can surface either after time works 
against the probabilities or if the distributions shift during use. 
| D could be particularly helpful when software has passed all planned tests using D. 
Faults that are only sensitive to infrequent inputs (according to D) could be more likely to 
be uncovered by D, particularly if the reason such faults are “good” hiders is that they are 


rarely executed according to D, but they are reached by D. 
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5.3.3 D and Sensitivity Analysis 


In this section, we examine what information we can glean from sensitivity analysis when we 
substitute D for D. Sensitivity analysis using D identifies code locations that are unlikely to 
cause failures when rare inputs are seen. These locations can either: (1) contain design logic 
flaws or (2) be input statements that read corrupted external data that is coming into the 
software from the system that it is controlling. To illustrate the importance of sensitivity 


analysis using the two distributions, we consider four extreme cases: 


1. A particular location (or module or program) is insensitive under both distributions.® 
This location is unlikely to reveal any faults during testing. It is therefore a prime 
candidate for formal methods or other non-empirical verification schemes. A fault in 
this location would be very difficult to find during testing with D, so any remaining 


faults are potential surprises after release. 


2. A particular location is sensitive under D but insensitive under D. Testing using 
D will likely reveal faults. But during operation, we have a confidence that if the 
code experiences any problems similar to the “mimiced” faults used during sensitivity 


analysis, the code is self-correcting enough to not fail. 


3. A particular location is insensitive using D, but sensitive using D. This location will 


benefit from testing using D. 


4. A particular location is sensitive under both distributions. Testing using either distri- 


bution is likely to reveal any faults. 


Besides the significance for debugging, sensitivity analysis based on D can also help to 
predict a likely probability of failure for a piece of software. The smallest remaining errors 
are the most difficult to find, and traditional testing is limited in giving assurance about 
very “small” faults (i.e., those that result in a very small probability of failure). Sensitivity 
analysis can help in this regard: if sensitivity analysis can demonstrate that very large faults 
are unlikely (i.e., faults will tend to be “small,” and therefore unlikely to be triggered during 


operation), then additional confidence should be allowed in the “Squeeze Play” (based on D 


®High sensitivity implies low fault tolerance, and insensitivity implies high fault tolerance [16]. 


and testing) that no failures will occur. More information on the squeeze play can be seen 


in {23].° 


5.3.4 Examining the Improbable Input Subdomain for Fault Tolerance 


Assume that D was expressed as a relatively small number of “bins,” where each bin contains 
a set of inputs all of which have the same probability of selection during software use. We 
will characterize the bin using that probability, so that we will discuss “likely bins” and 
“unlikely bins.” Now apply sensitivity analysis one bin at a time, essentially eliminating the 
influence of D’s bin selection frequencies. When we analyze a bin of inputs that are unlikely 
(but not impossible) to be chosen under D, we are examining if faults are likely to reveal 
themselves (if they exist) when the software is executed with inputs from this bin. If they 
are not, we have evidence of fault-tolerance. 

When we are interested in whether or not testing will discover faults (see previous sec- 
tion), low sensitivity is discouraging. But fault tolerance requires that software be robust 
and able to recover from unexpected problems, as well as not “reveal” problems if they exist. 
That is, the software should be able to somehow recover from a software fault or corrupted 
input and produce correct (or at least acceptable) output. During testing, we want faults 
_ revealed; during fault tolerant execution, we want faults “covered up.” 

If testing is based primarily on a particular input distribution, then inputs in a low 
probability bin of that distribution are less likely to trigger failures during execution. The 
software segments exercised by these bins are, therefore, more likely to contain undiscovered 
faults. However, if the software has high fault-tolerance when executing low probability 
input test cases, faults are likely to remain hidden during operation; 1.e., the software will 


tolerate problems that arise during the operational life-time of the code. 


°The use of D strengthens the squeeze play; even if a location is likely to reveal faults with D and does not, 
and it is fault-tolerant to faults with D, then we have two pieces of information suggesting that during the 
life of the code according to D, failures will not occur. Whenever, according to the operational distribution. 
small sized faults can be shown to be unlikely to exist and the program appears to be fault-tolerant in the 
ultra-dependable region of the input space, i.e., the improbable input subdomain, the squeeze play becomes 
_ more practical. 
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5.3.5 D and OO Software 


From Task 2, we know that assertions are a relatively low-cost tool for increasing the testa- 
bility of D. Task 3 provided a way to assess the testability of D, and in those regions where 
this assessment is lacking, we again have the option to inject assertions. The assertions from 
Task 2 are a function of D, whereas assertions based on D are a function of D. It is curious 
to us whether the assertions based on D increase the testability for D and vice versa. We 
expect so, however that is future research; this is a possible task in Phase II. 

Realize that D is a special case of input distribution independence, which is of particular 
interest in trying to develop dependability models that have fewer restrictions that con- 
ventional reliability models. If we could show that, in general, testabilities are not heavily 
biased towards any particular distribution, meaning that the testabilities from D, D, and 
any other distribution between these extremes are similar, then we could possibly create a 


dependability model that has this independence characteristic. 


5.3.6 Task 3 Summary 


Task 3 has suggested two areas in which examining low probability inputs can enhance our 
understanding of OO software testability: (1) during testing, we can look for faults in order to 
remove them; and (2) when assessing fault tolerance, we can examine whether infrequently 
selected inputs are likely to mask resident faults or corrupt input data. In both these 
areas, sensitivity analysis based on D quantifies unique information that can be immediately 
combined with the results of Task 2 to assess where assertions may be warranted. 

Our expectations are that D will not be useful during testing, since fixed testing resources 
must be reserved for those test cases that the system is likely to encounter. Hence D will 


likely only be used for critical systems with known operational profiles. 


5.4 Task 4: Verifying the Impact of Task 2 and Task 3 Recom- 


mendations 


This task applies the recommendations developed in Task 2 to verify the increase in testa- 
bility one might expect using assertions. Here, RST has empirically tested the benefit of the 


recommendations from Task 2, and reanalyzed the modified C++ ATM code to assess the 
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Original Propagation 


Propagation After Assertion | 
1.0 


rec->type = ret_val; 
rec->transaction = WITHDRAW; 
rec->type = ret_val; 
rec->transaction = DEPOSIT; 
ret_val = CHECKING; 
rec->type = ret_val; 
RecordNumber = 0; 

RECORDMAX = 30; 


Table 7: The “before and after” propagation point estimate location scores for 
OO-ATM. 


change in testability. Due to resource limitations, we were unable to apply the recommen- 
dations to the SHAPES experiment due to the cost of implementing D. | 

In the C++ ATM code, we have identified eight locations in the C++ code that are 
of particularly low testability. Although the procedural code did have low testability loca- 
tions, we are interested in showing improved OO code testability, and so we did not apply 
our recommendations to that code. (We expect similar gains in testability had we applied 
assertions to the procedural code.) 

For each of the low testability locations in the C++ version, an assertion was manually 
placed immediately following the location, and the testability analysis was rerun. Here, we 
did not assume that the code was correct, but we believe that the assertions were correct. 
Recall from our earlier discussion that after an assertion is injected, it then is a location 
that contributes to the output space, and hence the functional definition of what constitutes 
failure for the system is also modified. These assertions have forced each propagation point 
estimate to increase to 1.0, which is a remarkable increase in the testability of the code with 
respect to the 102 test cases (See Table 7). 

In Task 4, we were unable to perform the distribution inversion technique with the 102 


test cases on either the OO or procedural ATM code for two reasons: 
1. The test cases are currently not mapped to any particular distribution, and 


2. A test case is a multi-dimensional vector, not a simple mathematical operand, like an 


integer or floating-point value. 


To have enabled us to do so on this code would have required more resources than this effort 
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provided. This is a possible task in Phase II. 


5.4.1 Task 4 Summary 


Task 4 has demonstrated that assertions increase propagation (and hence testability) as the 
lemma showed. Not only did the assertions increase propagation point estimates, but to 
1.0. This demonstrates the power that assertions possess. Given that Task 1 has suggested 
that OO systems appear to be at a propagation deficit when encapsulation and information 


hiding are present, assertions should be considered before system level testing is performed. 


5.5 Task 5: Feasibility of Implementing an Assertion Injector 


Task 5 examined the results of the previous tasks to determine whether there are tools that 
should be built to: (1) improve the testability of OO systems or (2) assess their testability. 
During Task 1, RST Corporation built a rudimentary C++ front-end onto its Testability 
Tool for PiSCES Software Analysis Toolkit'?™). Although far from commercial grade, this 
tool can be refined into a commercial grade product. Given that this software testability 
assessment prototype is on its way to being implemented, we must determine whether a 
prototype tool can be built for NIST that would assist in improving OO system testability. 

As we have seen, strategically placed assertions are “powerful” mechanisms for improving 
the fault detection capability of system level testing. The results of Task 4 document the 
importance of such a capability. As for the implementability of such a tool, we envision a 


tool with the following capabilities: 


1. The ability to read in a raw PiSCES output file to determine where assertions are 


needed and on which portion of the state. 


2. An interactive meta-language in which the user will specify the pre or post-conditions 


that will determine if the state is “okay” or unacceptable. 


3. The ability to read the user supplied conditions and convert that into executable source 


code that is automatically inserted into the source code before testing begins. 


Additionally, we plan to modify our C+4 testability assessment tool to recognize assertions 


that are injected as a result of this innovation if the user wishes to reassess testability, and 
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immediately flag those assertions as “output points.”!° 

From the results of the Phase I project and the success of the assertions, RST will propose 
to build a prototype assertion injector during a Phase II program. The difficult challenge 
of that effort will be to design the meta-language in which the pre and post cond '':ns are 
specified by the user. Our current plans are to use a scheme similar to the one currently 
supported by the C-Patrol tool described in [3], which is partially based on Eiffel object 


invariants that are placed on all operations to an object {13]. 


5.5.1 Task 5 Summary 


From a Phase II effort, NIST stands to not only gain access to a C++ software testability 
assessment capability, but it will receive a tool that will engender the use of assertions where 


assertions are most needed. 
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A Code from ATM Experiment 


A.1 Object-Oriented (C++) Version 


#define CHECKING i 
#define SAVINGS 2 
#define CANCEL 3 
#define WITHDRAW 4 
#define DEPOSIT 5 
#define TRANSFER 6 
#define NUM 7 
#define BALANCE 8 


#define ERROR -1 


struct Account { 
int AccountNo; 


double Balance; 


3; 


struct CustomerRecord { 
char lastname[32]; 
char firstname[32]; 
char middle[32] ; 
int pin; 
unsigned int Accounts; 
struct Account CustomerAccounts[2] ; 


1 


class Bank { 


private: 


int RECORDMAX; 


int RecordNumber ; 
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struct CustomerRecord BankRecords [30]; 


char Database[32]; 


public: 
Bank(char []); 
~Bank(); 


int CheckRecords (struct CustomerRecord &); 


void ModifyRecords (struct CustomerRecord *) ; 


ty 


class KeyPad { 
private: 

int number; 
public: 
KeyPad() {} 
“KeyPad() {} 
int ReadKeyPunches() ; 
int GetNumber(); 
Ls 


class Console { 
private: 

public: 

Console() de 
“Console() {} 

void Display(char *); 
void Clear(); 

pe 


class CardReader { 


private: 


char ‘Card[32] 


$4 


public: 
CardReader() {} 
“CardReader() {} 
char *ReadCard() ; 
void EjectCard() ; 
void EatCard() ; 
¥; 


class Receipt { 
public: 
cvaccoun., 
int type; 
float amount; 
int transaction; 
class Receipt *next; 
Receipt() {} 
“Receipt() {} 
z; 


class ATM { 
private: 


struct CustomerRecord CurrentRecord; 


Bank *bank_link; 


KeyPad keypad; 
Console console; 
CardReader cardreader; 


Receipt *receipts; 


void ReadInPin() ; 
void TransactionLoop() ; 
void WithdrawFunds(); 


void DepositFunds() ; 
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void CheckBalance() ; 

void TransferFunds() ; 
public: 

ATM(Bank &); 

“ATM() ; 

void AcceptCard(); 


void AddReceipt(Receipt *); 


void PrintReceipts(); 


dy 
#include <stdio.h> 
#include <string.h> 


#anelude “atmih" 


anc 


KeyPad: :ReadKeyPunches() { 


char buffer[30]; 


scanf("/s", buffer): 


if (index(buffer, ’q’)) 
return CANCEL; 

else if (index(buffer, 
return WITHDRAW; 

else if (index(buffer, 
return DEPOSIT; 

else if (index(buffer, 
return TRANSFER; 

else if (index(buffer, 
return CHECKING; 

else if (index(buffer, 
return SAVINGS; 

else if (index(buffer, 


return BALANCE; 


tw? )) 


Hq?) : 


+t?) ys) 


Gp) 
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else { 
number = atoi(buffer); 


return NUM; 


int 
KeyPad::GetNumber() { 


return number; 


void 

Console: :Display(char *line) { 
printit Gifs’ line); 

in 


void 
Console::Clear() { 
printt@\n\n"); 


i, 


char * 


CardReader: :ReadCard() { 


static’ char buffer[32); 


scant ('Y.s'" butter) ; 


return buffer; 


void CardReader: :EjectCard() { 
} 
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void CardReader: :EatCard() { 
} 


ATM: :ATM(Bank &bank) { 


bank_link = &bank; 
receipts = NULL; 


console.Clear(); 


console.DispLay ('U OO d\n!) 5 


console.Display("* Welcome to RST’s ATM Machine *\n") ; 


console.Display (1433 n\n") ; 


ATM: :~ATM() { 
P 


“void 
ATM: :AcceptCard() 


{ 
FILE *fp; 


char *CurrentCard; 


console.Display("Please input your card > "); 


CurrentCard = cardreader.ReadCard(); 


if ((fp = fopen(CurrentCard, "r'")) == NULL) { 
console.Clear(); 


console.Display("Cannot read your card, call RST bank\n") ; 
cardreader .EjectCard() ; 


6xit(-1):; 
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fscanf(fp, "4s %s Us", CurrentRecord.lastname, CurrentRecord.firstname, 


CurrentRecord.middle) ; 
fclose(fp) ; 
if ('!bank_link->CheckRecords(CurrentRecord)) { 
console.Clear(); 
console.Display("Invalid card, call RST bank\n") ; 


cardreader .EjectCard() ; 


exit(-1): 


ReadInPin(); 


void 
ATM: :ReadInPin() f{ 
int unsuccessful = 0, flag = 1; 
char line[80]; 
/* Acknowledge customer */ 
sprintf(line, "\n\nHello, %s %s 4s\n", CurrentRecord.firstname, 
CurrentRecord.middle, 
CurrentRecord.lastname) ; 
console.Display(line) ; 
/* read in pin until found, transaction canceled, or card eaten */ 


while (unsuccessful < 3 && flag) { 


console.Display("Enter your PIN number or hit c to cancel> "); 
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switch (keypad.ReadKeyPunches()) { 

case CHECKING: 
console.Display("\nInvalid entry, try again\n"); 
break; 

case SAVINGS: 
console.Display("\nInvalid entry, try again\n"); 
break; 

case CANCEL: 
console.Display("\nCancel selected, goodbye!\n") ; 

cardreader .EjectCard() ; 

break; 

case WITHDRAW: 
console.Display("\nInvalid entry, try again\n"); 
break; 

case DEPOSIT: 
console.Display("\nInvalid entry, try again\n"); 
break; 

case TRANSFER: 
console.Display("\nInvalid entry, try again\n"); 
break; 

case BALANCE: 
console.Display("\nInvalid entry, try again\n"); 
break; 

case NUM: 
if (keypad.GetNumber() != CurrentRecord.pin) { 


/* mark an unsuccessful try */ 
console.Display("\nIncorrect PIN number\n\n") ; 
unsuccessful+tt+; 

continue; 


} else 


/* found valid pin, break out of loop */ 
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/* if too many tries, eat card */ 


if (unsuccessful == 3) { 
console.Display("\n\nPlease see your bank concerning your card\n"); 
cardreader.EatCard() ; 
exiti—1)% 

} else 


/* successful access */ 
TransactionLoop() ; 
void 
ATM: :TransactionLoop() { 
int ret_val = 0; 
while(ret_val != CANCEL) { 
console.Display("\n\nChoose a transaction> "); 
switch(ret_val = keypad.ReadKeyPunches()) { 
case WITHDRAW: 
WithdrawFunds() ; 
break; 


case DEPOSIT: 
DepositFunds() ; 


ol 


break; 
case BALANCE: 


CheckBalance(); 
break; 
case TRANSFER: 
TransferFunds() ; 
break; 
} 
void : 


ATM: :WithdrawFunds() { 


int ret_val = 0; 


while(ret_val != CANCEL && ret_val != CHECKING && ret_val != SAVINGS) { 
console.Display("From: "); 
switch(ret_val = keypad.ReadKeyPunches()) { 
case CHECKING: 


case SAVINGS: 
if (((CurrentRecord.Accounts & CHECKING) && (ret_val == CHECKING)) || 


((CurrentRecord.Accounts & SAVINGS) && (ret_val == SAVINGS))) { 
console.Display("\nHow much do you wish to withdraw? "); 


keypad.ReadKeyPunches() ; 


if (CurrentRecord.CustomerAccounts[ret_val-1].Balance < keypad.GetNumber()) { 
console.Display("\nSorry, insufficient funds\n") ; 
ret_val = CANCEL; 

} else { 


Receipt *rec = new Receipt; 


rec->account = CurrentRecord.CustomerAccounts[ret_val-1] .AccountNo; 
rec->type = ret_val; //ASSERT 
rec->amount = keypad.GetNumber() ; 


rec->transaction = WITHDRAW; //ASSERT 
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rece 


AddR 


Curr 
ret_ 

} 
} else { 


consol 


>next = NULL; 


eceipt (rec) ; 


entRecord.CustomerAccounts[ret_val-1].Balance -= keypad.GetNumber() ; 


val = CHECKING; 


e.Display("\nSorry, you don’t have that type of account\n"); 


return; 


void 


break; 


ATM: :DepositFunds() { 


int ret_val = 0; 


while(ret_val '= CANCEL && ret_val != CHECKING && ret_val '= SAVINGS) { 


console.Display("To: "); 


switch( 
case 


case 


ret_val = keypad.ReadKeyPunches()) { 

CHECKING: 

SAVINGS: 

if (((CurrentRecord.Accounts & CHECKING) && (ret_val == CHECKING)) 


((CurrentRecord.Accounts & SAVINGS) && (ret_val == SAVINGS))) { 


console.Display("\nHow much do you wish to deposit? "); 


keypad.ReadKeyPunches() ; 


Receipt *rec = new Receipt; 


rec->account = CurrentRecord.CustomerAccounts[ret_val-1].AccountNo; 


rec->t 


ype = ret_val; //ASSERT 


rec->amount = keypad.GetNumber () ; 


rec->transaction = DEPOSIT; //ASSERT 
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rec->next = NULL; 


AddReceipt (rec) ; 


CurrentRecord.CustomerAccounts [ret_val-1].Balance += keypad.GetNumber() ; 


ret_val = CHECKING; //ASSERT 
} else { 
console.Display("\nSorry, you don’t have that type of account\n") ; 


return; 


break; 


void 

ATM: :CheckBalance() { 
int ret_val = 0; 
char buffer[80] ; 


while(ret_val != CANCEL && ret_val != CHECKING && ret_val '!= SAVINGS) { 
console.Display("For: "); 
switch(ret_val = keypad.ReadKeyPunches()) { 
case CHECKING: 
case SAVINGS: 


if (((CurrentRecord.Accounts & CHECKING) && (ret_val == CHECKING)) 


((CurrentRecord.Accounts & SAVINGS) && (ret_val == SAVINGS))) ¢{ 


Receipt *rec = new Receipt; 


rec->account = CurrentRecord.CustomerAccounts[ret_val-1] .AccountNo; 


rec->type = ret_val; //ASSERT 


rec->amount = CurrentRecord.CustomerAccounts [ret_val-1i].Balance; 
rec->transaction = BALANCE; 


rec->next = NULL; 
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AddReceipt (rec) ; 


ret_val = CHECKING; 
} else { 
console.Display("\nSorry, you don’t have that type of account\n") ; 


return; 


break; 


void 
ATM: :TransferFunds() { 


int ret_val = 0; 


while(ret_val != CANCEL && ret_val != CHECKING && ret_val != SAVINGS) { 
console.Display("From: "); 
switch(ret_val = keypad.ReadKeyPunches()) { 
case CHECKING: 
if (((CurrentRecord.Accounts & CHECKING) && (ret_val == CHECKING)) ||, 
((CurrentRecord.Accounts & SAVINGS) && (ret_val == SAVINGS))) { 


console.Display("\nHow much do you wish to transfer? "); 
keypad.ReadKeyPunches() ;. 
if (CurrentRecord.CustomerAccounts [CHECKING-1].Balance < keypad.GetNumber()) { 
console.Display("\nSorry, insufficient funds\n") ; 
ret_val = CANCEL; 
} else { 


Receipt *rec = new Receipt; 


rec->account = CurrentRecord.CustomerAccounts[ret_val-1].AccountNo; 
rec->type = ret_val; 


rec->amount = keypad.GetNumber() ; 


rec->transaction = TRANSFER; 
rec->next = NULL; 


AddReceipt (rec) ; 


CurrentRecord.CustomerAccounts[CHECKING-1].Balance -= keypad.GetNumber() ; 


CurrentRecord.CustomerAccounts[SAVINGS-1].Balance += keypad.GetNumber () ; 


I 
ret_val = CHECKING; 
else { 


console.Display("\nSorry, you don’t have two accounts\n") ; 


return; 
break; 
case SAVINGS: 
if (((CurrentRecord.Accounts & CHECKING) && (ret_val == CHECKING)) || 
((CurrentRecord.Accounts & SAVINGS) && (ret_val == SAVINGS))) f{ 


console.Display("\nHow much do you wish to transfer? "); 

keypad .ReadKeyPunches() ; 

if (CurrentRecord.CustomerAccounts [SAVINGS-1].Balance < keypad.GetNumber()) { 
console.Display("\nSorry, insufficient funds\n") ; 
ret_val = CANCEL; 

} else { 


Receipt *rec = new Receipt; 


rec->account = CurrentRecord.CustomerAccounts[ret_val-1].AccountNo; 
rec->type = ret_val; 

rec->amount = keypad.GetNumber() ; 

rec->transaction = TRANSFER; 

rec->next = NULL; 


AddReceipt (rec) ; 


CurrentRecord.CustomerAccounts[SAVINGS-1].Balance -= keypad.GetNumber () ; 
CurrentRecord.CustomerAccounts[CHECKING-1].Balance += keypad.GetNumber() ; 
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} 
ret_val = SAVINGS; 
} else { 
console.Display("\nSorry, you don’t have two accounts\n") ; 


return; 


break; 


void 


ATM: :AddReceipt(Receipt *receipt) 
“3 
if (!receipts) 
receipts = receipt; 
else { 
Receipt *front = receipts; 
receipts = receipt; 


receipts->next = front; 


void 

ATM: :PrintReceipts() 

af 

for( Receipt *rec = receipts; rec; rec = rec->next) { 
//printf ("Account no: %d\n", rec->account) ; 
//PiSCES Output Point 
pi_write_data( (char *) &rec->account, sizeof (rec->account)) ; 
switch(rec->transaction) { 
case WITHDRAW: 
printf ("Withdraw from %s\n", 


of 


((rec->type == CHECKING) ? "Checking" : "Savings")); 
//printf ("Amount = %41f\n\n", (float) rec->amount) ; 
//PiSCES Output Point 
pi_write_data( (char *) &rec->amount, sizeof (rec->amount)) ; 
break; 
case DEPOSIT: 
printf("Deposit to %s\n", 
((rec->type == CHECKING) ? "Checking" : "Savings")); 
//printf("Amount = %1f\n\n", (float) rec->amount) ; 
//PiSCES Output Point 
pi_write_data( (char *) &rec->amount, sizeof (rec->amount)) ; 
break; 
case TRANSFER: 
printf("Transfer from %s to 4s\n", 
((rec->type == CHECKING) ? "Checking" : "Savings"), 
(rec->type == CHECKING ? "Savings" : "Checking")); 
//printf("Amount = %1f\n\n", (float) rec->amount) ; 
//PiSCES Output Point 
pi_write_data( (char *) &rec->amount, sizeof (rec->amount)) ; 
break; 
case BALANCE: 
printf("Balance for %s\n", 
(rec->type == CHECKING ? "Checking" : "Savings")); 
//printf("Amount = %1f\n\n", (float) rec->amount) ; 
//PiSCES Output Point 


pi_write_data( (char *) &rec->amount, sizeof (rec->amount)) ; 


break; 


Bank: :Bank(char Records[]) { 
FILE *fp; 
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RecordNumber = 0; //ASSERT 
RECORDMAX = 30; // ASSERT 


strcpy(Database, Records) ; 


if ((fp = fopen(Records, "r")) == NULL) { 
//printf("Invalid Records File\n"); 
//PiSCES output point. 
pi_write_data("Invalid Records File\n",22) ; 


exieC-1)e 


Rhilectscant (pss 4s 45°45 4d Ad, BankRecords[RecordNumber] .firstname, 
BankRecords[RecordNumber] .middle, 
BankRecords [RecordNumber] .lastname, 
&BankRecords[RecordNumber].pin, 


&BankRecords[RecordNumber].Accounts) != EOF) { 


if (BankRecords[RecordNumber].Accounts & CHECKING) { 
facant (ipeeede,lt", 
&BankRecords [RecordNumber] .CustomerAccounts[0] .AccountNo, 


&BankRecords [RecordNumber] .CustomerAccounts[0] .Balance) ; 


ci 


if (BankRecords[RecordNumber].Accounts & SAVINGS) f{ 
fscanttips “Advil 
&BankRecords [RecordNumber] .CustomerAccounts[1].AccountNo, 


&BankRecords [RecordNumber] .CustomerAccounts[1].Balance) ; 


} 


RecordNumbert+; 
if (RecordNumber == RECORDMAX) 


break; 


59 


fclose(fp) ; 


Bank::~Bank() { 
FILE *fp; 


/* if ((fp = fopen(Database, "w'')) == NULL) { 
fprintf(stderr,"Error saving records, Transactions lost\n") ; 
fflush(stderr) ; 


exit(-1); 


for (int x = 0; x < RecordNumber; x++) { 
Porters (te eers) 5s 0d d\n", 
BankRecords[x].firstname, BankRecords[x] .middle, 
BankRecords[x].lastname, BankRecords[x].pin, 
BankRecords [x] .Accounts) ; 


if (BankRecords[RecordNumber].Accounts & CHECKING) { 
Peusner (fp \t hd. Alf \n", 
BankRecords[RecordNumber] .CustomerAccounts[0] .AccountNo, 


BankRecords [RecordNumber] .CustomerAccounts[0] .Balance) ; 


if (BankRecords[RecordNumber].Accounts & SAVINGS) { 
Serine C a \tLG Alt \n", 
BankRecords [RecordNumber] .CustomerAccounts[1].AccountNo, 


BankRecords [RecordNumber] .CustomerAccounts[1] .Balance) ; 


F 
fclose(fp) ;*/ 
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int 
Bank: :CheckRecords(struct CustomerRecord &record) f{ 


for (int x = 0; x < RecordNumber; x++) 
if (!strcmp(BankRecords[x].lastname, record.lastname) && 
'strcmp(BankRecords[x].firstname, record.firstname) && 
'strcmp(BankRecords[x].middle, record.middle)) { 
record.pin = BankRecords[x] .pin; 
record.Accounts = BankRecords[x].Accounts; 
fersitantiey = 0; y < 2; y++) £ 
record.CustomerAccounts[y].AccountNo = 
BankRecords [x] .CustomerAccounts[y] .AccountNo; 
record.CustomerAccounts[y].Balance = 
BankRecords [x] .CustomerAccounts[y] .Balance; 
} 
break; 


if (x >= RecordNumber) 
return co): 
else 


return(1); 


main(int argc, char *argv[]) { 


if (arpes<e2) ad 
//fprintf(stderr,"Usage: atm <database>\n"); 
//PiSCES output point. 
pi_write_data("Usage: atm <database>\n",24); 
fflush(stderr) ; 


exit(-1); 
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Bank bank(argv[1]); 
ATM atm(bank); 


atm.AcceptCard() ; 


atm.PrintReceipts() ; 


A.2 Procedural (C) Version 


#define CHECKING 1 
#define SAVINGS 2 
#define CANCEL 3 
#define WITHDRAW 4 
#define DEPOSIT 5 
#define TRANSFER 6 
#define NUM 7 
#define BALANCE 8 


#define ERROR -1 
int number; 


void AcceptCard() ; 

void LoadDatabase(); 
void ReadPinNumber() ; 
void TransactionLoop() ; 
void PrintReceipts() ; 
void WithdrawFunds () ; 
void DepositFunds() ; 
void CheckBalance() ; 


void TransferFunds(); 
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char CurrentCard[32] ; 
FILE *fp; 


struct Receipt { 
int account; 
int type; 
float amount; 
int transaction; 
struct Receipt *next; 


Be 


struct Receipt *receipt_list = NULL; 


struct Account { 
int AccountNo; 
double Balance; 


igh 


struct CustomerRecord { 
char lastname[32] ; 
char firstname([32] ; 
char middle[32]; 
int spin; 
unsigned int Accounts; 
struct Account CustomerAccounts [2]; 


} BankRecords [30] ; 


int RecordNumber ; 


#define RECORDMAX 30 


#include <stdio.h> 


Hinclude “atmean: 
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/* This program simulates a simplistic automated teller machine 
The notion comes from the CACM article "Object-oriented Integration 
Testing" by Jorgensen & Erickson. This test program is being 
used for RST’s DOC contract on 00 testability. 
Written by: Jeffery E. Payne - Reliable Software Technologies Corp. 


9/23/94 
* / 


main(argce, argv) 
int argc; 
char **argv; 
struct CustomerRecord CurrentRecord; 
/* check argument */ 
PPecarecu<. 2) {. 
fprintf(stderr,"Usage: atm <database>\n") ; 
fflush(stderr) ; 
exit(-1); 
/* Load in database of acceptable cards */ 
LoadDatabase(argv[1]) ; 


/* Read info from card */ 


AcceptCard(&CurrentRecord) ; 
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/* Read in pin information */ 
ReadPinNumber (&CurrentRecord) ; 
TransactionLoop(&CurrentRecord) ; 
PrintReceipts() ; 
/* LoadDatabase reads logged bank records into the teller so cards 
can be checked against valid pin numbers 
Written by: Jeffery E. Payne - Reliable Software Technologies 
9/23/94 
soul 
void 


LoadDatabase(Records) 


char *Records; 


{ 


/* open records file passed in from command line */ 
if ((fp = fopen(Records, "r")) == NULL) { 
printf("Invalid Records File\n"); 
exit(); 
/* read in all records in the file or until the bank records are full */ 


RecordNumber = 0; 


while(fscanf(fp, "%s %s ds Ud Ud", BankRecords[RecordNumber] .firstname, 


BankRecords [RecordNumber] .middle, 
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BankRecords [RecordNumber] .lastname, 
&BankRecords[RecordNumber] .pin, 


&BankRecords[RecordNumber].Accounts) != EOF) { 


if (BankRecords[RecordNumber].Accounts & CHECKING) { 
fscant(i pallidus ia, 

&BankRecords [RecordNumber] .CustomerAccounts[0].AccountNo, 
&BankRecords [RecordNumber] .CustomerAccounts[0] .Balance) ; 


} 


if (BankRecords[RecordNumber].Accounts & SAVINGS) { 
fiscantt fp id Wie" ; 

&BankRecords [RecordNumber] .CustomerAccounts[1].AccountNo, 
&BankRecords [RecordNumber] .CustomerAccounts[1].Balance) ; 


I 


RecordNumber++; 
if (RecordNumber == RECORDMAX) 
break; 


fclose(fp); 


/* AcceptCard accepts a bank card and determines whether it is valid or not. 


sieteeateinvaligvecne card is spit out 


Written by: Jeffery E. Payne - Reliable Software Technologies Corporation 
9/23/94 
Hj 


void 


AcceptCard(CurrentRecord) 


struct CustomerRecord *CurrentRecord; 
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Invexseys 
/* Welcome participant */ 
print? ("\n\n Lea a rE ara Tn ) ; 


printf("\n* Welcome to RST’s ATM Machine *\n"') ; 


pTUnté 0" pao ao aa aedcdd n\n) 5 


/* Have user put card into machine */ 


printf("Please input your card > "); 


Scant @'Y%s",) CurrentCard)’: 
/* check for validity of card */ 
if ((fp = fopen(CurrentCard, "r")) == NULL) { 


printf("Invalid card\n") ; 
exit(); 


/* read in information from card */ 


fscanf(fp, "%s ds 4s", CurrentRecord->lastname, CurrentRecord->firstname, 


CurrentRecord->middle) ; 


fclose(fp) ; 


/* check to see if card is from this bank, if so get pin number */ 


for (x = 0; x < RecordNumber; x++) 


if (!strcmp(BankRecords[x].lastname, CurrentRecord->lastname) && 


'strcmp(BankRecords[x].firstname, CurrentRecord->firstname) && 


'strcmp(BankRecords[x].middle, CurrentRecord->middle)) { 
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CurrentRecord->pin = BankRecords[x].pin; 
CurrentRecord->Accounts = BankRecords[x] .Accounts; 
for (y= "0; < 2: y++) { 
CurrentRecord->CustomerAccounts[y].AccountNo = 
BankRecords[x] .CustomerAccounts[y] .AccountNo; 
CurrentRecord->CustomerAccounts[y].Balance = 
BankRecords [x] .CustomerAccounts[y] .Balance; 
> 
break; 


f*eatieccard not on file +«/ 


if (x >= RecordNumber) { 
printf("Invalid Bank Card, Sorry\n"); 
exit();: 


/* ReadPinNumber reads a pin number and determines whether it matches 
bank records. If c is pressed the transaction is cancelled. A 
user gets three chances to get the pin number correct. After that 


the machine eats the card. 


Written by: Jeffery E. Payne - Reliable Software Technologies Corporation 
9/23/94 
*/ 


void 
ReadPinNumber (CurrentRecord) 
‘struct CustomerRecord *CurrentRecord; 
{ 
int unsuccessful = 0; 


int pin; 
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char buffer[32]; 


/* Acknowledge customer */ 


printf("\n\nHello, 4s %s 4s\n", CurrentRecord->firstname, 
CurrentRecord->middle, 


CurrentRecord->lastname) ; 


/* read in pin until found, transaction canceled, or card eaten */ 


while (unsuccessful < 3) { 


printf("Enter your PIN number or hit c to cancel> "); 


scant (/s'), butter): 

/* if cancel selected */ 

if i Gindex (buffer - 9ic",)) 4 
printf('"\nCancel selected, goodbye!\n"); 
exit(); 

+ else { 


/* make pin an integer and check against bank records */ 


pin = atoi(buffer) ; 


if (pin != CurrentRecord->pin) { 
/* mark an unsuccessful try */ 
printf("\nIncorrect PIN number\n\n") ; 
unsuccessfult+; 


continue; 


} else 
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/* found valid pin, break out of loop */ 


break; 
} 


/* if too many tries, eat card */ 


if (unsuccessful == 3) { 
printf("\n\nPlease see your bank concerning your card\n"); 
6xitc): 


} else 
/* successful access */ 


printf("\nSuccessful access to bank account\n") ; 


void 
TransactionLoop(CurrentRecord) 


struct CustomerRecord *CurrentRecord; 
{ 


int ret_val = 0, number; 
while(ret_val '= CANCEL) f{ 
printf("\n\nChoose a transaction> "); 
ret_val = ReadKeyPunches(&number) ; 
switch(retival) + 
case WITHDRAW: 


WithdrawFunds(CurrentRecord) ; 


break; 
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case DEPOSIT: 
DepositFunds (CurrentRecord) ; 
break; 

case BALANCE: 
CheckBalance(CurrentRecord) ; 
break; 

case TRANSFER: 
TransferFunds(CurrentRecord) ; 


break; 


int 

ReadKeyPunches (number ) 
int *number; 

{ 

char bufferi([30] ; 


scant Gis") puffert): 


if (index(buffer1, ’q’)) 
return CANCEL; 

else if (index(buffer1, ’w’)) 
return WITHDRAW; 

else if (index(buffer1, ’d’)) 
return DEPOSIT; 

else if (index(bufferi, ’t’)) 
return TRANSFER; 

else if (index(buffer1, ’c’)) 
return CHECKING; 

else if (index(buffer1, ’s’)) 
return SAVINGS; 

else if (index(buffer1, ’b’)) 
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return BALANCE; 
else { 
*xnumber = atoi(buffer1); 


return NUM; 


void 

WithdrawFunds (CurrentRecord) 

struct CustomerRecord *CurrentRecord; 
{ 


int ret_val = 0, number; 


while(ret_val != CANCEL && ret_val != CHECKING && ret_val != SAVINGS) f{ 

pointe (From: 3"); 
ret_val = ReadKeyPunches(&number) ; 
switch(ret_val) { 

case CHECKING: 

case SAVINGS: 

if (((CurrentRecord->Accounts & CHECKING) && (ret_val == CHECKING)) || 

((CurrentRecord->Accounts & SAVINGS) && (ret_val == SAVINGS))) { 
printf("\nHow much do you wish to withdraw? "); 
ReadKeyPunches(&number) ; 
nib (CurrentRecord->CustomerAccounts[ret_val-1] .Balance < number) { 

printf("\nSorry, insufficient funds\n"); 

ret_val = CANCEL; 
} else { 


struct Receipt *rec = (struct Receipt *) malloc(sizeof(struct Receipt)); 


rec->account = CurrentRecord->CustomerAccounts[ret_val-1] .AccountNo; 
rec->type = ret_val; 

rec->amount = number; 

rec->transaction = WITHDRAW; 


rec->next = NULL; 


(iy: 


if (receipt_list != NULL) f{ 
struct Receipt *tmp_rec = receipt_list; 
receipt_list = rec; 
rec=2nexts= Wmpcrec; 

} else 


receipt _list = rec; 


CurrentRecord->CustomerAccounts[ret_val-1].Balance -= number; 
ret_val = CHECKING; 
} 
} else { 
printf("\nSorry, you don’t have that type of account\n") ; 


return; 


break; 


void 

DepositFunds (CurrentRecord) 

struct CustomerRecord *CurrentRecord; 
{ 


int ret_val = O, number; 


while(ret_val != CANCEL && ret_val != CHECKING && ret_val != SAVINGS) { 

printtGiiast') ; 
ret_val = ReadKeyPunches(&number) ; 
switch(ret_val) { 

case CHECKING: 

case SAVINGS: 

if (((CurrentRecord->Accounts & CHECKING) && (ret_val == CHECKING)) || 
((CurrentRecord->Accounts & SAVINGS) && (ret_val == SAVINGS))) { 


struct Receipt *rec = (struct Receipt *) malloc(sizeof(struct Receipt)); 
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printf("\nHow much do you wish to deposit? "); 


ReadKeyPunches (&number) ; 


rec->account = CurrentRecord->CustomerAccounts[ret_val-1] .AccountNo; 
rec->type = ret_val; 
rec->amount = number; 
rec->transaction = DEPOSIT; 
rec->next = NULL; 
if (receipt_list != NULL) { 
struct Receipt *tmp_rec = receipt_list; 
receipt_list = rec; 
rec-snext = tmp_rec; 
} else 


receipt_list = rec; 


CurrentRecord->CustomerAccounts [ret_val-1].Balance += number; 
ret_val = CHECKING; 

} else { 
printf("\nSorry, you don’t have that type of account\n") ; 


return; 


break; 


void 
CheckBalance(CurrentRecord) 
struct CustomerRecord *CurrentRecord; 
{ 
anteretival¥=s;0; 


char buffer[80]; 


while(ret_val != CANCEL && ret_val != CHECKING && ret_val != SAVINGS) { 
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printiForip) 3 
ret_val = ReadKeyPunches(&number) ; 
switch(ret_val) { 

case CHECKING: 


case SAVINGS: 
if (((CurrentRecord->Accounts & CHECKING) && (ret_val == CHECKING)) || 


((CurrentRecord->Accounts & SAVINGS) && (ret_val == SAVINGS))) f{ 
struct Receipt *rec = (struct Receipt *) malloc(sizeof(struct Receipt)) ; 


rec->account = CurrentRecord->CustomerAccounts[ret_val-1] .AccountNo; 
rec->type = ret_val; 
rec->amount = CurrentRecord->CustomerAccounts[ret_val-1] .Balance; 
rec->transaction = BALANCE; 
rec->next = NULL; 
if (receipt_list != NULL) { 
struct Receipt *tmp_rec = receipt_list; 
receipt_list = rec; 
rec-onext = tmp_rec; 
} else 


receipt_list = rec; 
ret_val = CHECKING; 


} else { 
printf("\nSorry, you don’t have that type of account\n"); 


return; 


break; 


void 


TransferFunds(CurrentRecord) 
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struct CustomerRecord *CurrentRecord; 


A 


int ret_val = 0, number; 


print? C"From:.”) ; 
ret_val = ReadKeyPunches(&number) ; 
switch(ret_val) { 
case CHECKING: 
if (((CurrentRecord->Accounts & CHECKING) && (ret_val == CHECKING)) 
((CurrentRecord->Accounts & SAVINGS) && (ret_val == SAVINGS))) ¢{ 


ReadKeyPunches (&number) ; 


while(ret_val != CANCEL && ret_val != CHECKING && ret_val '= SAVINGS) { 


printf ("\nHow much do you wish to transfer? "); 


if (CurrentRecord->CustomerAccounts [CHECKING-1].Balance < number) { 


printf("\nSorry, insufficient funds\n") ; 


ret_val = CANCEL; 
else { 


struct Receipt *rec = (struct Receipt *) malloc(sizeof (struct Receipt)); 


rec->account = CurrentRecord->CustomerAccounts[ret_val-1] .AccountNo; 


rec->type = ret_val; 
rec->amount = number; 
rec->transaction = TRANSFER; 
rec->next = NULL; 

if (receipt_list != NULL) { 


struct Receipt *tmp_rec = receipt_list; 
receipt_list = rec; 


rec->next = tmp_rec; 


} else 


receipt_list = rec; 


CurrentRecord->CustomerAccounts[CHECKING-1].Balance -= number; 


CurrentRecord->CustomerAccounts[SAVINGS-1].Balance += number; 
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} 
ret_val = CHECKING; 
} else { 


printf("\nSorry, you don’t have two accounts\n") ; 


return; 


break; 
case SAVINGS: 
if (((CurrentRecord->Accounts & CHECKING) && (ret_val == CHECKING)) || 
((CurrentRecord->Accounts & SAVINGS) && (ret_val == SAVINGS))) { 


printf("\nHow much do you wish to transfer? "); 
ReadKeyPunches(&number) ; 
if (CurrentRecord->CustomerAccounts[SAVINGS-1] .Balance < number) { 
printf("\nSorry, insufficient funds\n") ; 
ret_val = CANCEL; 
} else { 


struct Receipt *rec = (struct Receipt *) malloc(sizeof(struct Receipt)) ; 


rec->account = CurrentRecord->CustomerAccounts[ret_val-1] .AccountNo; 
rec->type = ret_val; 
rec->amount = number; 
rec->transaction = TRANSFER; 
rec->next = NULL; 
if (receipt_list != NULL) { 
struct Receipt *tmp_rec = receipt_list; 
receipt_list = rec; 
rec->next = tmp_rec; 
} else 


receipt_list = rec; 


CurrentRecord->CustomerAccounts [SAVINGS-1] .Balance -= number; 


CurrentRecord->CustomerAccounts [CHECKING-1].Balance += number; 
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ret_val = SAVINGS; 
} else { 
printf("\nSorry, you don’t have two accounts\n") ; 


return; 


break; 


void 
PrintReceipts() 
af 
struct Receipt *rec; 
for(rec = receipt_list; rec != NULL; rec = rec->next) { 
printf("Account no: %d\n", rec->account) ; 
switch(rec->transaction) { 
case WITHDRAW: 
printf("Withdraw from %s\n", 


(rec->type == CHECKING ? "Checking" : "Savings")); 
printf("Amount = %1f\n\n", (float) rec->amount) ; 
break; 


case DEPOSIT: 
printf("Deposit to %s\n", 
(rec->type == CHECKING ? "Checking" : "Savings")); 
printf("Amount = 41f\n\n", (float) rec->amount) ; 
break; 

case TRANSFER: 
DEinct (Pl ranst crt romy,.Sato vein 5 
(rec->type == CHECKING ? "Checking" : "Savings"), 
(rec->type == CHECKING ? "Savings" : "Checking")); 
printf("Amount = %1f\n\n", (float) rec->amount) ; 
break; 


case BALANCE: 
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printf("Balance for %s\n", 

(rec->type == CHECKING ? "Checking" : "Savings")); 
printf("Amount = %1f\n\n", (float) rec->amount) ; 
break; 
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